Summary

Supersedes #3317

Configuration

• The Partial macro has been removed. The macro was hiding some important information, and that caused problems where some fields were Option<T>, and others were T.
• All fields are Option<T>, and all fields must be Option. As a consequence, the macro #[serde(skip_serializing_if = "Option::is_none")] needs to be implemented for all fields. This was already done for rules and actions. Failing to implement the macro will result in some snapshot regressions, so we're good here and can catch bugs early.
• Consistent naming. All structs are suffixed with *Configuration
• Added a new Bool type that holds at build time the default value of the bool assigned. This value is then assigned to the relative setting.
• Due to how bool values functioned in our toolchain, we were forced to use methods called is_disabled. This is no longer an issue thanks to the new Bool type, so now we can use is_enabled everywhere.

Settings

• The most significant change is how the workspace computes when whether a file is enabled for a certain feature. There are four occurrences: top-level configuration, language configuration, override top-level configuration, override language configuration. The priority is (first has most priority):

  1. overrides.langauges.css.formatter.enabled
  2. overrides.formatter.enabled
  3. langauges.css.formatter.enabled
  4. css.formatter.enabled

  The main problem was that every time we needed to add a new language to the toolchain, it was very easy to miss updating the new functionality. Now, this functionality has been moved to the ServiceLangauge level. The ServiceLanguage is used by the workspace to implement common functionality that must be supported by all languages. This means that we need to update ServiceLanguage only when we add a new capability. When adding a new language, the code won't compile until all the functions of the ServiceLanguage are implemented.

  As you might have guessed, we would need to update the ServiceLanguage trait in case we add a new feature (like we did with the search). We add languages more often than features, so that's the more maintainable solution.

• A new method called unwrap_settings was created, which is used instead of get_settings. Why? Because the absence of Settings inside a project should be an error, not a possibility. Biome always creates Settings, even when biome.json isn't present. In fact, we have already raised an error (only in one occurrence) in case settings aren't found. However, I left many method signatures to Option<&Settings> because the PR was becoming too big. I plan to that change that later.

• There were a lot of missing features, like assist, that weren't implemented. One more reason why implementing things at ServiceLanguage level should improve the internal DX of the codebase.

Capabilities

• I introduced a new set of capabilities. The capability is called enabled_for_path, and each member of the type EnabledForPath checks if a certain feature (formatter, linter, assist and search) is enabled for the given path. The functions are very simple, and they are meant to call the ServiceLanguage functions via WorkspaceSettingsHandle. See ### Settings, first bullet point.

Missing things that I will implement later

• Change all Option<&Settings> to &Settings
• Pass WorkspaceSettingsHandle to methods instead of &Settings. WorkspaceSettingsHandle is what needs to be used all over, because it's the type that is meant to hold the settings coming from the IDE.
• Add search to the configuration (and relative sub configurations, per language), so users can configure which files can be searched or not. This isn't implemented nowadays

Test Plan

The majority of CLI tests should pass.
The rage snapshots changed, and they are fixed (you'll more unset).
The help snapshots have been updated too.